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(54) Radio communication network 

(57) A Service-based (Per-Class QoS Profile) QoS 
Framework is disclosedforGPRS/UMTS. For each MS/ 
UE, multimedia flows are classified and grouped into a 
set of QoS Classes. Flows of different QoS Classes are 



identified and differentiated to meet the specific trans- 
mission requirement of each QoS Class, Flows of the 
same QoS Class will be processed and forwarded 
across the network in the same way to meet the their 
QoS specifications. 
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Description 

[0001] This invention relates to radio communication 

ra002l kS General packet radio Service (GPRS) and its 
[ eTancement, enhanced GPRS (EGPRS), use a pack , 
et-mode transfer technique to provide h.gh-speed and 
low-speed data services to mobile users based on the 
current GSM systems. Coupled with the ^opmen 
of wide band code division multiple access (WCDMA) 
technology to provide broadband radio access, umver- 
saTmSelecommunication system (UMTS) will pro- 
vided packet data services based on the evolution from 
GPRS systems. In GPRS/UMTS, applications based on 
standarddataprotocolsaresupported, and interworking 

is defined with internet protocol O^^^L*** 
networks. Although several quality of service (QoS) pro- 
Sale defined, the notion of service different.ation be- 
tween the strict delay/bandwidlh constraint services and 
the genera! delay-insensitive data transfer serv.ces ,s 
not supported in current GPRS specrf.cat.ons. Th.s lack 
of clear service differentiation has been recognised to 
be problematic in meeting the everpushing need tc . use 
GPRS to support a wide variety of services wrth d.ffcrent 

QoS requirements. 

- r 0 003] One major problem in supporting QoS and ef- 
ectiviiy, service differentiation, in GPRS ,s that curren 
GPRS specifications do not support the coexistence of 
multiple flowaMervlcee for a subscriber. One single type 
of service is designated to a mobile station (MS) at- 
tached to the GPRS system with some pre-defined QoS 
Z me. For example, a packet data protocol (POP) con- 
text is created and associated one-to-one with an IP ad- 
dress of a MS. The PDP context defines the ransmis- 
sion information for the packets belonging to the same 
application. Consequently all packets to and from the 
MS will be treated in the same way (the GPRS QoS pro- 
file) This single-flow QoS provisioning model of GPRS 
s very restrictive in supporting a multimedia apphcat.on 
which contains multiple media components and ongh 
nLsmultipieflowsof packer 
ferent packet delivery requirements in terms of delay, 

JETSSES S? '— - - - 

boS provisioning model, the media access cont ol 
(MAC) protocol defined In GPRS does not provide dis- 
Kn between different flows with different QoS re 
dements, in particular, there is no explicit support or 
Ll-time flows with bounded delay ^, em ents^M ore- 
over admission control is not properly defined in GPRS^ 
moisi There have been some proposals to expand 
he single-flow QoS provisioning model of GPRS by in- 
troducing multiple PDP sub-contexts (or secondary con- 
texts) in addition to an original PDP context. Each sub- 
context has an associated QoS for a specific flow within 
a mSmedia session. The packets belonging to the 
same flow whose transmission attributes are defined by 
Z pqP sub-context are treated in the same way while 



the packets belonging to different flows with different 
PDP sub-contexts are treated distinctively so as to meet 
the different QoS requirements. 
[0006] Several problems have been envisaged wrth 
this fine-grain QoS support model. The number of sub- 
contexts and subsequently the number of PDP sub-con- 
text activations increase in proportion to the number of 
media components as contained in multimedia session 
for an MS. This per-flow PDP will present a big concern 
in terms of control complexity and the number of PDP 
sub-contexts that need to be maintained and dynami- 
cally managed in the GPRS support nodes (GSNs) 
which may well form a many-to-many inter-connect ion 
networking pattern between serving GSNs (SGSNs) 
and gateway GSNs (GGSNs), each serving a large 
number of multimedia MSs. In addition, this fine-gram 
QoS notion may well be largely compromised at the IP 
layer and MAC layer where only a limited set of service 
differentiation is available. Finally it requires some sub- 
stantial changes over current GPRS flow handling 
mechanisms such as PDP sub-Context (secondary 
PDP Context) Activation/Release. This will inevitably in- 
crease the control complexity. 

[0007] The reader is directed to the following refer- 
ences: 
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EN 301 344 V6.4.0 (1999-08), "Digi^ cellular tele- 
communications systems (Phase 2+); General 
Packet Radio Service (GPRS); Service description; 
Stage 2 (GSM 03.60 version 6.4.0 Release 1997) 
EN 301 349 V6.4.0 (1999-07), " Digital cellular tele- 
communications system (Phase 2+); General Pack- 
et Radio Service (GPRS); Mobile Station (MS) - 
Base Station System (BSS) interface; Radio Link 
Control/ Medium Access Control (RLC/MAC) proto- 
col (GSM 04.60 version 6.4.0 Release 1997). 
GSM 09.60 V6.3.0 (1999-04), "Digital cellular tele- 
communications system (Phase 2+); General Pack- 
et Radio Service (GPRS); GPRS Tunnelling Proto- 
col (GTP) across the Gn and Gp interface; (GSM 
09 60 version 6.3.0 Release 1997). 
3G TR 23.907 1.3.0 (1999-05), u 3 rd Generation 
Partnership Project; Technical Specification Group 
Services and System Aspects QoS Concept (3G TR 
23 907 version 1 .3.0). 

3G TS 23.121 V3.0.0 (1999-07), " 3 rd Generation 
Partnership Project; Technical Specification Group 
Services and Systems Aspects; Architectural Re- 
quirements for Release 1999 (3G TS 23.121 ver- 
sion 3.0.0) 

[0008] The invention is based on the concept of serv- 
ice differentiation by a set of QoS Classes (or Service 
Classes) instead of on each micro-flow as proposed in 
GPRS. Moreover, to support the multimedia services 
with diverse QoS requirements, the concept of multi- 
service PDP (MPDP) and multiservice GPRS tunnelling 
procedure (MGTP) are introduced to exploit the current 
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* Maximum Bit Rate 

* Delivery order 

* Maximum SDU Size 

* SDU format information 
5 * Reliability 

* Transfer delay 

* Guaranteed Bit Rate 

* Burst Size 

* Traffic handling priority 

10 -* Allocation/Retention Priority 



GPRS specifications and definitions as much as possi- 
ble while minimising extra changes over current GPRS 
standards. 

[0009] Against this background there is provided a ra- 
dio communication network in which data flows between 
nodes in packets, and in which a plurality of flows relat- 
ing to a single mobile station, which flows are allocated 
the same or different quality of service classes, is con- 
trolled at one or more nodes by a single packet data pro- 
tocol context containing an indication of one quality of 
service profile or indications of a plurality of different 
quality of service profiles, flows allocated the same qual- 
ity of service being controlled by the same profile. 
[0010] One embodiment of the invention will now be 
described, by way of example, with reference to the ac- 
companying drawings, in which: 

Figure 1 is a flow diagram showing the procedure 
for activating an MPDP 

Figure 2 illustrates the fields I a modified QoS profile 
information element; 

Figure 3 shows how GTP protocol data units 
(G_PDUs) are dispatched through the MGTP; 
Figure 4 shows how service is differentiated at the 
logical link control (LLC)/MAC layers for uplink traf- 
fic at the MS; 

Figure 5 shows how service is differentiated for 
downlink traffic in the base station system (BSS); 
Figure s shows how service -is differentiated for up- 
link traffic in the BSS; and 

Figure 7 illustrates a modified control fields format. 

The Service Differentiation QoS Framework for 
GPRS/UMTS 

[0011] It is proposed that the QoS provision in GPRS/ 
UMTS is based on the QoS Classes or Service Classes. 
A limited number of QoS Classes are identified and the 
appropriate and minimum number of parameters are se- 
lected and defined to describe each QoS Class. All cur- 
rent and future applications are expected to be fully de- 
scribed by one QoS Class or a combination of the QoS 
Classes and the network delivery behaviour for the in- 
formation of the application is best described by the pa- 
rameters of the selected QoS Classes. 
[0012] As an example, the four QoS Classes (3GPP 
TR23.907) can be identified as the basic set of Service 
Classes based on which simple or complicated applica- 
tions can be built up. 

Conversational Service Class, 

* Streaming Service Class, 

* Interactive Service Class, 

* Background Service Class. 

[0013] As a reference, the following parameters are 
may best characterise the above QoS Classes. 



[0014] In the proposed QoS Framework, the multiple 
flows in a multimedia session are classified into the QoS 
Classes. A flow is identified by their corresponding QoS 

15 Class in those network functional elements/layers 
where Service Differentiation is performed. This means 
that flows of the same QoS Class will be treated the 
same way. Service Flows of different QoS Classes will 
be processed in different ways so as to maintain the 

20 service attributes as represented by the parameters of 
each QoS Class. 

[0015] In GPRS, Service Differentiation is performed 
at the MS, radio access network (RAN) (enhanced RAN 
or ERAN for EGPRS), SGSN and GGSN. Service Dif- 

25 ferentiation operations including both signalling and da- 
ta transmission procedures in GPRS are adapted, ex- 
tended and modified where necessary. The changes on 
current GPRS standard specifications should be kept to 
minimum while an effective service differentiation is 

30 achieved. 

[0016] As the basic building elements of the frame- 
work, MPDP Context and Multi-Service GTP adapted 
from the standard GPRS PDP Context and GTP Multi- 
Service Grouping are introduced to facilitate the 

35 achievement of service differentiation in GPRS net- 
works. 

[0017] A complete description of the GPRS QoS con- 
trol procedures is not included herein. Only those con- 
cepts and definitions that have been changed will be 
40 presented with associated explanations. 

Multi-Service PDP Context 

[0018] A Multi-Service PDP Context (MPDP) is .de- 
45 rived from the standard GPRS PDP Context. A PTP 
(Point-to-Point) GPRS subscription contains the sub- 
scription of one or more PDP addresses. An individual 
PDP Context in the MS, the SGSN, and the GGSN de- 
scribes each PDP address. A MPDP Context is gener- 
so ated for a subscription, which requests more than one 
QoS Classes. Please note that the number of flows is 
not necessarily equal to the number of QoS Classes. A 
subscription with more than one flow of the same QoS 
Class will activate a single-service PDP Context. A sin- 
55 gle-service PDP Context is taken as a special case of a 
MPDP Context. 

[0019] In a MPDP Context, a set of Per-Class QoS 
Profiles is defined in replace of the QoS profile in the 
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AarH PPRS PDP Context.The maximum number of 
standard GPRS PUK . g dec(ded 

Per ; C,aS mbef of he QoS Classes that have been iden- 

ssr- KcSS ss- * * mpdp context 

isfour " tn the Service Differentiation QoS 

100201 JH? netw^ servte access point indicator 
Framework, the netwo ^ exlended 

(N f P,) each of which corresponds to a 

t0 noS Class Rows belonging to the same sub- 
specific QoS Class . m ^ be ^ 
scrib er and hav - J e Q ^ number of 

9,6X6 T N SApt is nomSy equal to the number of the 
r S cTasses tnat a^ser his subscribed for and wishes 

t0 ^^S?Dp ( Sti«s'nalntalnedby MS, SGSN 
5? GGSN different. The differences are high- 

X£i %o "thTwPDP Context at the MS, two sets of 
[00221 For jned . Q ne set is the 

Per-Class QoS pn*-« ^ ^ other „ tne 

Requested Per-aaj « a Requcsted Per . 

S QOS pro;"' may be degrade' to a fower specifi- 
cation of the same ^ SGSN , three sets 

of Per-aass QoS proWe the second one is 

Subscnbed Per_Class u ^ ^ ^ 

the Requested P<^^J° A Negotiat ed Per-Class 
is the Negot.ated QoS J rts specifica tions 
QoS Profile is n^^«gajS^ ,n p i lto P lind1h . Re- 

set of Negotiated Per-Class Cos ^ro 

100251 ^"SKlSSto set of Radio 
the MS and the SGSN -s exten ^ ^ 

a VreTp D rco^ 

[0026] The MPDHU {hose Q( the 

Deactivation. Context Activation 

process, a MPDP Conte xt Request. The 

attheMStnggersAct^ateMP emuWmedla 

""^r oup < and'assmed into the number 

S6SS trusses that are authorised to the subsenber 
ofthoQoSCIassesthat ^ ^ 

A change on the i se tecte u ^ MpDp 

^2^^«*»- Addition/deletion of a 

SST T^Context Activation procedure is ...us- 



tratedin Figure 1 . Eachstep is explained in the following 
list. 
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1 1 The MS sends a Multi-Service Activate PDP Con- 
text Request, a message containing NSAPI, TO. 
PDP Type, PDP Address, Access Point Name, QoS 
RMuested and PDP Configuration Options, to the 
SGSN Th® MS uses the PDP Address to indicate 
SLl requiresthe use of astatic PDP address 
or whether it requires the use of a dynamic PDP ad 
d is The MS leaves the PDP Address empty to 
JeqTest a dynamic PDP address. The MS uses the 
Access Point Name to select a reference point to a 
Sain external network. The Access Pom Name 
(APN) is a logical name referring to an external 
St data network that the subscriber wishes to 
connect to. QoS Requested indicates the desired 
qoS profile. PDP Confutation Options may be 
used to requesi optional PDP parameters from the 
GGSN (see GSM 09.60). PDP Conftgumtion Op- 
tions is sent transparently through the SGSN. 

2) Security functions may be executed. 
3 > The SGSN validates the Multi-Service Activate 
PDP Context Request using PDP W lfP»"J. 
POP Address (optional), and Access Point Name 
(optional) provided by the MS and the PDP context 
subscription records. 

If no GGSN address can be derived or [the 
SGSN has determined that the Activate POP Con- 
fe* Request is not valid according to the rts ru es 
!hen the SGSN rejects the PDP context activation 

rSqU |f t GGSN address can be derived, the SGSN 
creates a tunnel identifier (TID) for the requested 
PDP context by combining the international mobile 
LbscS Identifier (IMS.) stored in the MM context 
with the NSAPI received from the MS. If the ^ re- 
quests a dynamic address, then the SGSN lets > a 
GGSN allocate the dynamic address. The SGSN 
Sy restrict the requested QoS attributes given its 
capabilities, the current load, and the subscribed 

Q0S The f (third generation) SGSN then sends a ra- 
dio access bearer (RAB) Service Request to the 
SSrSS estrial radio network (UTRAN). The re- 
quest contains the IMS., NSAPI, Row label up ink 
for SGSN SGSN IP address, and QoS negotiated. 
The UTRAN uses the Radio access bearer set up 
procedure to indicate to the mobile station or user 

er ID established and the corresponding NSAPI. 
The UTRAN replies with the RAB Serv,ce Re- 
sponse containing the MSI; NSAPI, Row label 
downlink for RNC, RNC IP address, and QoS ne- 

90ti Note that the NSAPI is sufficient to indicate the 
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QoS class. However, since the position of the Flow 
Label field within the GTP tunnel header makes it 
easier to manipulate, the Flow Label field can be 
used to indicate the QoS class, i.e. there is a one- 
to-one mapping between NSAPI and the Flow Label 
value. 

4) Only rf there are sufficient radio resources will the 
SGSN send a Create MPDP Context Request 
message containing PDP Type, PDP Address, Ac- 
cess Point Name, QoS Negotiated, TID, Selection 
Mode, and PDP Configuration Options, to the af- 
fected GGSN. The Access Point Name is the APN 
Network Identifier of the APN selected. The PDP 
Address is empty if a dynamic address is requested. 
The GGSN may use Access Point Name to find an 
external network. Selection Mode indicates wheth- 
er a subscribed APN was selected, or whether a 
non-subscribed APN sent by MS or a non-sub- 
scribed APN chosen by SGSN was selected. The 
GGSN may use Selection Mode when deciding 
whether to accept or reject the PDP context activa- 
tion. For example, if an APN requires subscription, 
then the GGSN is configured to accept only the PDP 
context activation that requests a subscribed APN 
as indicated by the SGSN with Selection Mode. The 
GGSN creates a new entry in its PDP context table 
and generates a Charging identity (Id). The new en- 
try allows the GGSN to route PDP PDUs between 
the SGSN and the external PDP network, and to 
start charging. The GGSN may further restrict QoS 
Negotiated given its capabilities and the current 
load. The GGSN then returns a Create PDP Context 
Response message containing the TID, PDP Ad- 
dress, Reordering Required, PDP Configuration 
Options, QoS Negotiated, Charging Id, and Cause, 
to the SGSN. The PDP Address is included if the 
GGSN allocated a PDP address. Reordering Re- 
quired indicates whetherthe SGSN shall reorder N- 
PDUs before delivering the N-PDUstothe MS. PDP 
Configuration Options contain optional PDP param- 
eters that the GGSN may transfer to the MS. These 
optional PDP parameters may be requested by the 
MS in the Activate PDP Context Request message, 
or may be sent unsolicited by the GGSN. PDP Con- 
figuration Options is sent transparently through the 
SGSN. The Create PDP Contexl messages are 
sent over the GPRS backbone network. 

[0029] Figure 2 shows the existing QoS Profile Infor- 
mation Element. It is proposed that an additional field 
called MGTP QoS class (1 byte) is added. The SGSN 
and GGSN will make use of the information stored in 
this field to mark the G_PDUs with appropriate QoS 
classes. 

[0030] Note also that the QoS Request, QoS Negoti- 
ated may contain two QoS Profile elements: one for up- 
link, one for downlink since it is likely that the traffic on 



the uplink and downlink is asymmetric with different QoS 
requirements. 

Multi-Service GTP 

5 

[0031] A Multi-Service GTP (MGTP) is derived from 
the standard GPRS GTP concept. A MGTP is defined 
both for the Gn interface, i.e. the interface between the 
GSNs (SGSN and GGSN) within a public land mobile 

10 -network (PLMN), and the Gp interface between GSN's 
in different PLMNs. A MGTP tunnel is set up for use of 
a multimedia session between an MS across the GPRS 
network to the GGSN. A MGTP allows multiprotocol 
packets that bear different QoS requirements to be tun- 

15 nelled through the GPRS backbone between GPRS 
Support Nodes (GSNs). 

[0032] An MGTP includes both the signalling and data 
transfer procedures. In the signalling plane, GTP spec- 
ifies a multi-service lu nnel control and management pro- 

20 tocol that allows the SGSN to provide a multimedia ac- 
cess for an MS to a GPRS network. Signalling is used 
to create modify and delete the multi-service tunnels. 
[0033] In the transmission plane, an MGTP uses a 
multi-service tunnel to provide a service for carrying 

25 multimedia data packets. Two packets belonging to two 
different flows of the same QoS Class will have the same 
TID and thus will be experiencing the same tunnelling 
behaviour between the SGSN and the GGSN. Only 
those packets bearing different QoS Classes will be for- 
30 warded in different ways through the tunnel across the 
GPRS GSNs according the specifications correspond- 
ing to their individual QoS Classes. The exact forward- 
ing behaviour is decided through Multi-Service Group- 
ing which maps a QoS Class as indicated in the TID to 

35 a specific internet protocol (IP) layer packet forwarding 
behavio ur, such as the differentiated service code points 
(DSCPs) corresponding to pre-defined per hop behav- 
iours (PHB's), assured forwarding(AF), expedited for- 
warding (EF) or default forwarding (DF) in DiffServ. 

40 [0034] The MGTP tunnel set-up, modification and de- 
letion procedures are similar to the standard specifica- 
tions of GPRS GTP, except that the TID for the G-PDU 
(GTP PDU) carries the QoS class that the current flow 
has been categorised into through the Multi-Service 

45 Grouping procedure. G_PDUs with the same TID (the 
same QoS Class) are multiplexed over the same type 
of Flow Labels (and hence NSAPIs) thai provides a spe- 
cific forwarding treatment to the G_PDUs. The IP pack- 
ets that encapsulate a G_PDU bear some appropriate 

50 information in its header (e.g. the DS filed) which decide 
its forwarding behaviour across the GSN's. The IP pack- 
et forwarding information is mapped from the QoS Class 
included in the TID through the Multi-Service Grouping 
procedure. 

55 [0035] In the signalling plane, the Create MPDP Con- 
text Request/Response messages, the Update MPDP 
Context Request/Response messages and the Delete 
MPDP Context Request/Response messages contain a 
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standard GPRS air | belongingto different QoS 
cided by the QoS .Class rt be g ^ q _ pDU 

b, ^?T^taferXheTS specifically indi- 
attachmg * ^TP lne G _ PD U belongs to. tr- 

eating the ^ ^ appropriate NSAPI is selected 

will h ave ^^^ r e Se ntsa particular. Pforv.ard- 
spond.ng Flow Label) rep w tQ a QqS 

jjB «-^^^JTJ^.«th. P |P layer uses DJf- 
Class of G PDUs jo provision ing, an IP packet 
ferentiated Services tor up has ^ 

sponding to the DSCP. 



the selected QoS Class over each network elements 
(MS, RAN/ERAN, SGSN/GGSNs) 

QoS Mapping: 

5 r0042] The QoS Class is mapped to specific sendee 
dass/priority levels at the network/MAC layer w.th the 
corresponding parameters translated. 
Si Multi-Service Grouping function may also m- 
,o ^w^monltortn8«ndpo«cln 8 ton^nth^ 
fic pattern within the pre-defined (or negotiated) 
qoS Profile. For example, the bit rate of an incoming 
Sficflow must be limited within its registered peak rate. 
Any packet found to have exceeded the specification , ,n 
15 Z » QoS.Profile will be either shaped (queued for a 
longer delay) or dropped. 



Service Differentiation at MS/UE 



20 r00441 TheServiceDifferentiationfunctionalitycar.be 
Ed at the temina. equipment (TE) from wh,ch an 
M PDP Context Activation Request ,s initiated in re 
„«* to the set-up request of a multimedia session. 
Sg the sisl sot-up, the MS/UE (MT) needs (TR 
25 23.907) to perform the Multi-Service Grouping function 

Jo045] Classify its media components into the corre- 

So^De^ 
30 budget for each selected QoS Class 

r0047] Map the QoS Classes and its parameters to 

Se lower layer (LLC/MAC or RLC/MAC) QoS Classes 

and the corresponding parameters. 

ro048] (optional) The MT may also need to monitor 

[00491 addition to the Multi-Service Grouping he 
Sarvto- Differentiation at the MS/UE also '"eludes the 
control operations for MPDP Context Act.vat.on/MGTP 
Set-up as described above. ,um 
40 fooso" During the data transfer, the MS/UE (MT) 
m«rks each packet with its corresponding QoS Class 
d and seSS the matching NSAPI with the appropriate 
[0039] Mu,ti-Se~ rad , acc essbearertodispatchthepacket. 
»^OT2==S» - S erv i ce D , fl e_inGS NNOd es(SGS N/G GS N ) 
eters and mapping tne w GT p/UDP layer and 

include the following procedures. 



Multi-Service Grouping Functions 



Flow Classif ication: 

aSSted qualitative/quantitative parameters. 
QoS Partitioning: 

[0041] The allocation of QoS budget corresponding 



r0051l For Service Differentiation at SGSN/GGSN, 
KLrvice Grouping needs to penned before 
and during data transfer between SGSN and GGSN. A 
50 MS/UE initiated multimedia service request withthe ^as- 
sociated QoS Classes needsto be authorised according 
to the subscribed QoS.Profiles. A multimedia service 
equest from an authorised user will also need to go 
through the admission control performed by the Murti- 
55 Service Grouping at the SGSN and GGSN. 

fo052] An authorised MS/UE that has been success- 
Euyaimlttedfor access to the network will baassigned 
the necessary network resources e.g. memory, central 
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processing unit (CPU), buffers for storing MPDP Con- 
text, transporting bearer data in the MGTP tunnel at the 
SGSN/GGSN. 

[0053] For the uplink traffic, a packet that arrives at 
the SGSN will be encapsulated by a GTP tunnel header 
with appropriate Flow Label and TID marking. The TID 
(IMSI+NSAPI) is used to select the corresponding tun- 
nel behaviour. Finally the G_PDU is dispatched through 
the NSAPI and transferred through the MGTP tunnel to 
the GGSN. The SGSN may also need to perform Multi- 
Service Grouping function (monitoring/policing/shap- 
ing) during the data transfer so as to guarantee that the 
traffic behaviour conforms to the negotiated 
QoS_Profile. 

[0054] For the downlink traffic, a packet that arrives 
at the GGSN from the external network will go through 
the similar processing as demonstrated in Figure 2. The 
Multi-Service Grouping (monitoring/policing/shaping) is 
performed by the GGSN before a G_PDU is dispatched 
to the lower network layer. 

Service Differentiation in ERAN 

[0055] Service differentiation at the ERAN (EGPRS 
Radio Access Network) is to categorise the user data 
PDUs according to their specific QoS Classes and put 
them in the corresponding queues at the LLC layer and 
finally selects the right radio channels to send the MAC 
frames carrying the LLC PDUs from different LLC 
queues. 

[0056] Figure 4 illustrates how different QoS classes 
can be supported at various layers at the MT User data 
packets, e.g. point to point protocol (PPP) frames, are 
classified and marked with different QoS classes 
through the Multi-Service Grouping process.. Then they 
are packaged into LLC PDUs, ^each of which bears a 
LLC type that is mapped from the QoS Class of the pack- 
ets and are placed into different queues that feature dif- 
ferent media access priorities Vendor specific schedul- 
ing algorithms can be used to schedule dispatching of 
LLC PDUs in the different queues for the uplink trans- 
missions. During the media access control, MT sends a 
packet resource request message specifying the LLC 
type. Upon hearing a radio uplink assignment message, 
MT can then fragment the LLC PDUs into appropriate 
RLC/MAC blocks and transmit them via the appropriate 
physical channels shown as M1 and M2 in Figure 3 . 
[0057] Figure 5 illustrates the procedure taken by the 
BSS to ensure that the uplink base station system 
GPRS protocol (BSSGP) PDUs bearing different QoS 
can be achieved. The BSS reassembles LLC frames 
and put thorn into different queues based on the LLC 
type. Then, again vendor specific scheduling algorithms 
can be used to schedule the transmission of these LLC 
frames to the SGSN. These LLC frames are encapsu- 
lated and sent as BSSGP PDU packets. 
[0058] Similarly Figure 6 illustrates the procedure tak- 
en by the BSS to ensure the differentiation at the LLC/ 



MAC layers for BSSGP PDUs with different QoS Class- 
es for the downlink traffic. BSSGP PDUs received by 
the BSS are decapsulated to reveal the LLC frame types 
and put in separate queues. Vendor specific downlink 

5 scheduling algorithms are used to transmit these LLC 
frames to the MAC Segmentation and Reassembly 
(SAR) sublayer where these LLC frames will be frag-, 
mented into different RLC/MAC blocks to be transmitted 
over different physical channels. 

w -[0059] One of the possible way of enhancing the LLC 
headers to include QoS information is to add an extra 
byte to the control field (at the top) to indicate different 
LLC type as shown in Figure 7. 
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Claims 

1 . A radio communication network in which data flows 
between nodes in packets, and in which a plurality 

20 of flows relating to a single mobile station, which 
flows are allocated the same or different quality of 
service classes, is controlled at one or more nodes 
by a single packet data protocol context containing 
an indication of one quality of service profile or in- 

25 dications of a plurality of different quality of service 
profiles, flows allocated the same quality of service 
being controlled by the same profile. 
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